Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links, segments and subnetworks. These entities are typically software processes executing on hardware computer platforms, such as end nodes and intermediate nodes. Communication software executing on the end nodes correlate and manage data communication with other end nodes. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
An intermediate node, such as a router, may interconnect the subnetworks to extend the effective “size” of the computer network. The router executes routing protocols used to direct the transmission of data traffic between the end nodes, such as hosts. Typically, the router directs network traffic based on destination address prefixes contained in the packets, i.e., the portions of destination addresses used by the routing protocol to render routing (“next hop”) decisions. Examples of such destination addresses include Internet Protocol (IP) version 4 (IPv4) and version 6 (IPv6) addresses. A prefix implies a combination of an IP address and a mask that cooperate to describe an area or range of the network that a router can reach, whereas a route implies a combination of a set of path attributes and a prefix.
Unicast data transfer (i.e., unicast forwarding) involves forwarding a data packet from a single sending process of an end node (“source”) to a single receiving process of an end node (“receiver”) on the computer network. Often the destination of the data packet issued by a source may be more than one, but less than all of the receivers on the network. This type of multicast data transfer (i.e., multicast forwarding) is typically employed to segregate communication between groups of receivers on the network. IP multicasting, in particular, may be used to disseminate data to a large group of receivers on the network.
To affect IP multicasting, the source generally specifies a destination IP address that is a multicast group address for the message and, as such, can only represent receivers of packets. The IPv4 (or IPv6) address range is subdivided into different prefixes, one of which is designated for use by IP multicast. Receivers typically notify their communication software of their desire to receive messages destined for the multicast group address; this is called “joining a multicast group”. These receiving members then “listen” on the multicast address and, when a multicast message is received at a receiver, it delivers a copy of the message to each process that belongs to the group.
IP multicasting relies on (i) a group management protocol to establish and maintain local multicast group membership, and (ii) multicast routing protocols to route packets efficiently. The Internet Group Membership Protocol (IGMP) manages packet communication between hosts and their local multicast router, letting them join or leave groups. That is, IGMP is used to send a group membership message from a host to its directly connected (“last-hop”) router, indicating that the host wants to join a group (address) as a receiver. Note that IGMP is an IPv4 group membership protocol; the conventional Multicast Listener Discovery (MLD) protocol is substantially similar to, and performs the same functions as, IGMP, but for IPv6. When group membership is established, multicast packets (identified by a multicast group address in the destination address field of an IP header) are forwarded between routers using multicast routing protocols.
Multicast routing protocols construct distribution trees through the network and direct multicast forwarding. The multicast distribution trees define the path that multicast traffic will take through the network to group members. These paths are based on source or shared multicast distribution trees. A multicast distribution tree is shared when any source (host) originating data traffic destined to a group address of a multicast group uses the same distribution tree to forward data to the receivers. In contrast, a source distribution tree is a separate, shortest path tree (SPT) built for each source originating traffic to the multicast group.
A rendezvous point is a specific router that is designated as the root of a shared multicast distribution tree. An announcement protocol is used to select and announce rendezvous points to all routers in the network. However, an alternative to using an announcement protocol to automatically advertise rendezvous points to all routers in the network is to manually configure the identity of the rendezvous points on all of the routers. Examples of such an announcement protocol include the Auto-RP multicast protocol available from Cisco Systems Inc. and the Bootstrap Router (BSR) described in Bootstrap Router (BSR) Mechanism for PIM Sparse Mode, Internet Engineering Task Force Internet-Draft, draft-ietf-pim-sm-bsr-03.txt, by Fenner, et al. February 2003. Examples of multicast routing protocols that use a rendezvous point include Protocol Independent Multicast-Sparse Mode (PIM-SM) and Bidirectional PIM (BIDIR-PIM) protocols. Other multicast protocols that do not require a rendezvous point include PIM dense mode (PIM-DM) and PIM source specific multicast (PIM-SSM) protocols.
IP multicast may be deployed on a computer network using a specific rendezvous point to build a shared multicast distribution tree for a multicast group falling within a destination address prefix or to build a separate SPT for each source originating traffic to the multicast group. Broadly stated, a router joins a multicast group (distribution tree) towards the rendezvous point or source. The interface on the router leading towards the rendezvous point or source is an ingress interface. Depending upon the multicast routing protocol, there is usually only one ingress interface on the router receiving multicast packets for a particular route. One or more interfaces on the router leading towards the hosts (receivers) are egress interfaces. The receivers are leaves or nodes on the distribution tree. Packets are sent from a source to the root (rendezvous point or source itself) of the distribution tree, where they are forwarded towards the branches and out to the nodes that represent the receivers. On each node, packets are received on the ingress interface towards the root of the tree and packets are forwarded out egress interfaces towards the receivers or nodes.
Specifically, a receiver uses IGMP to communicate a request to join a multicast group address to a last-hop router. The router communicates that request to its neighboring routers (neighbors) on the link towards the rendezvous point (for a shared tree) or source (for a SPT) using a multicast routing protocol, such as PIM. Auto-RP or BSR is used to distribute group range-to-rendezvous point address mapping configuration to all PIM-enabled routers that participate in the network topology. Collectively the routers construct a multicast distribution tree rooted at a rendezvous point or source for that group address and having a branch (link) that “pulls” packets towards the last-hop router. Note that only a single multicast router (forwarder) should forward packets for a route over a specific link of the tree.
The infrastructure of a router typically comprises functional components organized as a control plane and a data plane. The control plane includes the functional components needed to manage the traffic forwarding features of the router. These components include routing protocols, configuration information and other similar functions that determine the destinations of data packets based on information other than that contained within the packets. The data plane, on the other hand, includes functional components needed to perform forwarding operations for the packets.
For a single processor router, the control and data planes are typically implemented on the single processor. However, for some high performance routers, these planes are implemented within separate devices of the intermediate node. For example, the control plane may be implemented in a supervisor processor, whereas the data plane may be implemented within a hardware-assist device, such as a co-processor or a forwarding processor. In other words, the data plane is typically implemented in hardware that is separate from the hardware that implements the control plane.
The control plane generally tends to be more complex than the data plane in terms of the quality and quantity of software operating on the supervisor processor. Therefore, failures are more likely to occur in the supervisor processor when executing such complicated code. In order to ensure high availability in a router, it is desirable to configure the router such that if a failure arises with the control plane that requires restarting of software executing on the supervisor processor, the data plane continues to operate correctly. Restarting of control plane software may be necessary because of a failure with a routing protocol component or a software upgrade to that component. A router that is configured to enable its data plane to continue packet forwarding operations during restart of the control plane software is referred to as a non-stop forwarding (NSF) capable router.
Situations where a NSF capable router architecture is useful include both anticipated and non-anticipated failures in the control plane of the router. For example, failures in the control plane can include unanticipated or unplanned events (e.g., software crashes or hardware errors) as well as planned or anticipated events (e.g., scheduled maintenance). As for the latter, assume it is desired to upgrade software running on the supervisor processor or even remove and replace that processor for service. Such an upgrade or removal/replacement may cause an interruption in one or more routing protocols, but the NSF nature of the router allows continued forwarding of data through the router.
NSF router architectures have been implemented in unicast forwarding applications to enhance router availability and avoid disruption of data connectivity. These previous implementations often require modification of unicast routing protocols to add support to NSF. For example, modifications to a known unicast routing protocol allow support for graceful restart of router protocol failures. When the router is restarted, the modified protocol allows the router to obtain information (via protocol message exchanges) with its neighbors and without the neighbors “viewing” the router as being completely down, thereby obviating any changes to the routing topology.
U.S. patent application Ser. No. 10/897,959, titled System and Method for Preserving Multicast Data Forwarding during Control Failures in a Router, describes a multicast NSF router architecture that preserves multicast data forwarding through the router during NSF recovery of control failures without modifying existing multicast protocols. Various multicast components of the router cooperate to provide the multicast NSF architecture, including PIM and a multicast routing information base (MRIB) executing in a control plane of the router, as well as a multicast forwarding information base (MFIB) executing in a data plane. The MFIB is derived from the MRIB and is embodied as one or more multicast forwarding tables whose contents describe how to forward data packets through the router.
NSF recovery in the multicast router involves efficient restarting of a failed multicast component, such as PIM, and rebuilding of state based on conventional PIM protocol messages until all necessary information has been recovered. During NSF recovery, the control plane is disconnected from the data plane, which essentially “freezes” the contents of the MFIB multicast forwarding table. That is, any changes that occur in the control plane are not communicated to the data plane and are not reflected in the current MFIB that is used for forwarding data traffic. Thus, changes to network conditions are not acted upon within the data plane for the duration of the recovery period. As a result, the MFIB “blindly” forwards data traffic through the router using the frozen contents of its forwarding table.
However certain network condition changes, such as changes in unicast forwarding, which arise during the time that the MFIB forwards data traffic using its frozen (“stale”) forwarding information may cause neighbors of the router to change their multicast forwarding. Multicast protocols generally depend on the full recursive state of unicast protocols. Changes to network topology that affect unicast forwarding, such as reverse path forwarding (RPF) state, may cause the neighbors to change their multicast forwarding and begin sending multicast data traffic on a different path (link). For example, a neighbor may change its multicast forwarding so that data traffic received from the router over a particular link for a particular route is forwarded back over that link onto the same interface from which the router forwarded that traffic. This results in multiple multicast forwarders on the link, which could possibly result in the generation of duplicate packets and the formation of a multicast loop.
Multicast loops are generally much worse than unicast loops. In the case of unicast forwarding, a packet traverses a unicast loop until a router decrements a time-to-live (TTL) parameter of the packet to zero, at which time the packet is discarded. Yet in the case of multicast forwarding, each time the packet traverses a multicast loop and “hits” a router that has more than one egress interface, the packet is replicated, thereby resulting in an explosion of packets. It is thus desirable to avoid the generation of duplicate packets and the possible formation of multicast loops.